What about changing isset( $parsed ) to ! empty( $parsed )?

how about adding an http (or https) on the URL if it’s missing, then proceed as it is now?

An example of a URL that's causing this is:
///wp-includes/js/jquery/jquery.js
It's not a missing protocol, just a relative URL - no host name specified. So prefixing with http(s) won't change anything.

empty() returns a true on empty strings as well as integer, float and string '0'/zero values. So it's a bit inaccurate in some cases. If, somehow, the domain name is '0' (unlikely, I know, but...) it'll think it's empty when it isn't. That's why I'm suggesting the change submitted. :)

is this potentially happening anywhere else? (maybe stylesheets as well)

@johnbillion thoughts?

Yes, it looks like it could be happening in block_style_load() as well but I haven't seen any deprecated warnings in the log file from that.

Where are those three leading slashes on the URL coming from?

I don't know. It could be from the theme (Astra on this test site). I didn't dig too deep on that since it's not affecting the call to parse_url() itself.

ok i'm aware this is over a year old and i'm gonna blame the pandemic.

doing some quick testing, i'm finding that a relative URL correctly using two slashes (//wp-includes/..) will give me a string i can check for. but one with three slashes (///wp-includes/js/jquery/...) returns false, since it can't be parsed.

so was that 3rd slash a typo, or was that actually the attempted URL to load? because wp_enqueue_script wouldn't even load that file correctly.